Comments
-
BTW - I left things alone and got distracted by other tasks - but today I thought about it again and just for grins I pinged the problem interface - AND IT WORKED! No changes were made to the SW - somehow this appears to have been an ISP issue - and it fixed itself as mysteriously as it appeared. Ugh...
-
@BWC I just saw that question - the status is "available" thanks again. mike
-
@BWC Thanks for the quick reply, Michael. x3 is included in my failover/load balancing group and it is actually the primary. There has been no effort to remove it. I just tried changing probing on x2 to physical only and it had no effect, so switched it back to logical. It says target alive. I ssh'ed in and did a show…
-
@BWC Prioritize routes by metric within route classes = NOT selected Never generate an interface-specific default route = NOT selected So yes, I think this is the problem as well - but I don't understand why the two x2 routes are greyed out. below default (auto added) routes 11 & 12 are greyed out. all x2 routes have lower…
-
Alright - have noticed an anomaly in the route policies x5 has 3 policies x3 has 4 polices x2 has 3 policies but 2 are greyed out (not enabled) x1 has 3 policies All policies are auto added and I can't re-enable the 2 disabled policies and don't understand how they were disabled in the first place. The greyed out polices…
-
@BWC sorry - I'm doing something wrong when I use "quote" so just pasting your comment here. >>do I get this correct, when you ping the IP of X2 from the Internet you can see the "echo request" arriving on X2 but the "echo reply" leave the appliance on X3 according to the Packet Monitor? YES. And with a decent SonicWall…
-
Hi Michael- yes all interfaces are separate IPs the only ones that start with even the same triplet are x1 and x5. With Sonic support we checked NATs, Access rules, Routes 2 or 3 times and nothing leapt out at us. This x2 interface has been pingable since 2018. For this behavior to happen all of a sudden is puzzling.…